Check if this issue is valid — if so, understand the root cause and fix it. At objects/obj_formation_bar/Create_0.gml, line 194:

<comment>The PR adds another identical `if (unit_id == 18)` block to an existing chain of 17 identical blocks, continuing a pattern of repeated code fragments that should be abstracted into a function or lookup table.</comment>

<file context>
@@ -191,6 +191,9 @@ mouse_release = function(){
 	            if (unit_id == 17) {
 	                obj_controller.bat_whirl_for[obj_controller.formating] = mah_target.col_parent;
 	            }
+	            if (unit_id == 18) {
+	                obj_controller.bat_bike_for[obj_controller.formating] = mah_target.col_parent;
+	            }
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/scr_company_order/scr_company_order.gml, line 191:

<comment>Repeated squad-type traversal boilerplate in `role_hierarchy()` — two consecutive loops duplicate the same nested iteration over `obj_ini.squad_types` and their keys. Merge into a single pass or extract a helper function.</comment>

<file context>
@@ -194,5 +184,79 @@ function role_hierarchy() {
+    // so they sort immediately after the generic sergeant, keeping them at the top of their squads
+    var _sgt_base  = _roles[eROLE.SERGEANT];
+    var _vsgt_base = _roles[eROLE.VETERANSERGEANT];
+    var _squad_type_names = struct_get_names(obj_ini.squad_types);
+    for (var _si = 0; _si < array_length(_squad_type_names); _si++) {
+        var _sq_data = obj_ini.squad_types[$ _squad_type_names[_si]];
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/scr_company_order/scr_company_order.gml, line 249:

<comment>Excessive nesting depth (more than 3 levels) in the non-sergeant role variant loop within `role_hierarchy()`.</comment>

<file context>
@@ -194,5 +184,79 @@ function role_hierarchy() {
+                    array_contains(_role_def.alternative_roles, _base_roles[_bi])) {
+                    var _bpos = array_get_index(hierarchy, _base_roles[_bi]);
+                    if (_bpos >= 0) {
+                        array_insert(hierarchy, _bpos + 1, _specific_role);
+                        break;
+                    }
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/scr_UnitGroup/scr_UnitGroup.gml, line 278:

<comment>Raw string literals 'Sergeant' and 'Veteran Sergeant' used as repeated identifiers should be replaced with #macro or enum constants.</comment>

<file context>
@@ -222,20 +223,74 @@ function UnitGroup(units) constructor {
+                var _role_name = squad_unit_types[r];
+                var _role_def = _fill_squad[$ _role_name];
+                var _primary_role_name = struct_exists(_role_def, "role") ? _role_def.role : _role_name;
+                if (_primary_role_name == _sgt_type || (_role_name == "Sergeant" && _sgt_type == sgt_types[0]) || (_role_name == "Veteran Sergeant" && _sgt_type == sgt_types[1])) {
+                    _sgt_group = _role_name;
+                    break;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/scr_UnitGroup/scr_UnitGroup.gml, line 228:

<comment>Repeated sergeant-role-group lookup logic appears three times within `create_squad` and should be extracted into a shared helper to reduce maintenance debt and risk of inconsistency.</comment>

<file context>
@@ -222,20 +223,74 @@ function UnitGroup(units) constructor {
         var _fulfilled = false;
+        //adding multiple role sources on gen within a single squad
+        var _all_roles_to_fetch = array_create(0);
+            for (var r = 0; r < array_length(squad_unit_types); r++) {
+            var _primary_role = squad_unit_types[r];
+            var _primary_role_def = _fill_squad[$ _primary_role];
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/scr_promote/scr_promote.gml, line 132:

<comment>The 100-iteration guard silently swallows either a bug or an oversized company rather than surfacing it. `create_squad` has persistent side effects (mutates `obj_ini.squads`, rewrites roles, assigns `squad` UIDs), so if it ever returns `true` without fully consuming members, this loop could fire up to 100 times and then continue as if promotion finished successfully. Likewise, a large company that legitimately needs more than 100 squads of the same role would be silently truncated. Consider tracking actual progress (e.g., verifying that each successful call reduced the pool of eligible squadless units) and adding an explicit assertion or log when the cap is reached so the condition is not silently ignored.</comment>

<file context>
@@ -125,8 +125,13 @@ function setup_promotion_popup() {
+                    // success without exhausting members. No company holds anywhere near 100 squads
+                    // of one type, so this cap only trips on a genuine bug rather than normal play.
+                    var _squad_guard = 0;
+                    while (_result[0] && _squad_guard < 100) {
                         _result = _grp.create_squad(role_squad_equivilances[$ role_name[target_role]]);
+                        _squad_guard++;
</file context>